GermanWikipedia - /page/entry.mu

Micron Document

<!DOCTYPE html>

<title>Routing Information Protocol</title>

</head>

<h1 id="firstHeading" class="firstHeading mw-first-heading"><span class="mw-page-title-main">Routing Information Protocol</span></h1>

</header>

</div>

<caption>RIP im <a href="Internetprotokollfamilie#TCP/IP-Referenzmodell" title="Internetprotokollfamilie">TCP/IP-Protokollstapel</a>:

</caption>

<th class="hintergrundfarbe4">Anwendung

</th>

<th colspan="5" class="notheme hintergrundfarbe6">RIP

</th></tr>

<tr>

<td class="hintergrundfarbe8">Transport

</td>

</td></tr>

<tr>

<td class="hintergrundfarbe8">Internet

</td>

<td colspan="5" class="notheme" style="background:#EEEEFF; color:#202122;"><a href="Internet_Protocol" title="Internet Protocol">IP</a> (<a href="IPv4" title="IPv4">IPv4</a>, <a href="IPv6" title="IPv6">IPv6</a>)

</td></tr>

<td class="hintergrundfarbe8">Netzzugang

</td>

<td><a href="Ethernet" title="Ethernet">Ethernet</a>

</td>

<td><a href="Token_Bus" title="Token Bus">Token<br>Bus</a>

</td>

<td><a href="Token_Ring" title="Token Ring">Token<br>Ring</a>

</td>

</td>

<td>…

</td></tr></tbody></table>

<p>Das <b>Routing Information Protocol</b> (<b>RIP</b>) ist ein <a href="Routing" title="Routing">Routing</a>-<a href="Netzwerkprotokoll" title="Netzwerkprotokoll">Protokoll</a> auf Basis des <a href="Distanzvektoralgorithmus" title="Distanzvektoralgorithmus">Distanzvektoralgorithmus</a>, das innerhalb eines <a href="Autonomes_System" title="Autonomes System">autonomen Systems</a> (z. B. LAN) eingesetzt wird, um die <a href="Routingtabelle" title="Routingtabelle">Routingtabellen</a> von <a href="Router" title="Router">Routern</a> automatisch zu erstellen.

Es gehört zur Klasse der <a href="Interior_Gateway_Protocol" title="Interior Gateway Protocol">Interior Gateway Protocols</a> (IGP).

</p><p>RIP wurde zuerst in RFC 1058 (1988) definiert. Das Protokoll wurde seitdem mehrfach erweitert und liegt nun als RIP Version 2 (RFC 2453) vor.

</p><p>Beide Versionen werden noch heute eingesetzt, jedoch werden sie als technisch veraltet betrachtet und sind durch neuere Protokolle wie <a href="Open_Shortest_Path_First" title="Open Shortest Path First">Open Shortest Path First</a> (OSPF) oder das <a href="Open_Systems_Interconnection" class="mw-redirect" title="Open Systems Interconnection">OSI</a> Protokoll <a href="IS-IS" title="IS-IS">IS-IS</a> abgelöst worden.

</p><p>RIP wird in den Protokollen <a href="Internet_Protocol" title="Internet Protocol">IP</a> und <a href="Internetwork_Packet_Exchange" title="Internetwork Packet Exchange">IPX</a> benutzt und wurde unter dem Namen

RIPng (RIP next generation) im RFC 2080 (1997) erweitert, um auch IPv6 zu unterstützen.

</p>

<div class="mw-heading mw-heading2"><h2 id="Überblick"><span id=".C3.9Cberblick"></span>Überblick</h2></div>

<p>Beim Starten eines Routers kennt dieser nur seine direkt angeschlossenen <a href="Rechnernetz" title="Rechnernetz">Netzwerke</a>. Ein neuer Router sendet daher auf jedem RIP-konfigurierten Interface eine Aufforderung an alle seine Nachbarn mit der Bitte um Zusendung ihrer vollständigen Routingtabelle. Aus den erhaltenen Antworten errechnet der fragende Router die ersten Einträge seiner noch ungefüllten Routingtabelle. Im Anschluss daran schickt er ein triggered Update mit seiner neu erstellten Routingtabelle an alle RIP-Nachbarn, so dass diese ihrerseits über eventuelle neue Wege informiert werden.

</p><p>RIPv1 kennt keine Subnetzinformationen. Ein Router kann daher Subnetze nur auf zwei Wegen berücksichtigen: entweder er nutzt die an seinem Interface speziell konfigurierte Subnetzmaske oder er zieht die Standardsubnetzmaske heran. Auf Grund dieser Einschränkung können über RIPv1 verwaltete Netze nicht <a href="Variable_Length_Subnet_Mask" title="Variable Length Subnet Mask">VLSM</a> oder verteilte Subnetze berücksichtigen.

</p><p>Um Änderungen im Netzwerk (Ausfall oder Start eines Routers) zu erkennen, wird das Senden der Routingtabellen – das sogenannte <i>Advertisement</i> – regelmäßig (alle 30 Sekunden bei IP) wiederholt, dabei wird stets die gesamte Routingtabelle jedoch nur an alle direkten Nachbarn gesendet. Die Routinginformationen breiten sich damit relativ langsam im Netz aus, bei einer maximalen Ausdehnung des Netzes von 15 Routern ("Hops") beträgt die Zeitdauer bereits sieben Minuten. Zudem ist nicht garantiert, dass die Informationen bei den benachbarten Routern ankommen, da die Advertisements über <a href="User_Datagram_Protocol" title="User Datagram Protocol">UDP</a> versendet werden, die Übertragung also nicht zuverlässig ist.

</p><p>Die Kosten (auch <i>Metrik</i>) bezeichnen den Aufwand, um ein bestimmtes Netz zu erreichen. Beim Protokoll RIP wird zur Berechnung der Metrik allein der <a href="Hop_(Netzwerktechnologie)" title="Hop (Netzwerktechnologie)">Hop Count</a> verwendet; er bezeichnet die Anzahl der Router, die entlang eines Pfades bis zum Zielnetz durchlaufen werden müssen. Im Gegensatz zu anderen Routing-Protokollen lässt RIP damit die Bandbreite mehrerer zur Auswahl stehender Wege unberücksichtigt. Bei RIP für IPX wird zusätzlich noch der Tick-Count benutzt; er bezeichnet die Verzögerung eines Paketes durch alle Router bis zum Zielnetz.

</p><p>Im Gegensatz zu <a href="Open_Shortest_Path_First" title="Open Shortest Path First">OSPF</a> und <a href="NetWare_Link-Services_Protocol" title="NetWare Link-Services Protocol">NLSP</a> kennt ein RIP-Router immer nur seine direkten Nachbarn. Bei Änderungen im Netzwerk dauert es eine gewisse Zeit, bis alle Router wieder eine einheitliche Sicht auf das Netzwerk haben. Mit Erreichen dieses Zustandes spricht man von <a href="Konvergenz_(Netzwerk)" title="Konvergenz (Netzwerk)">Konvergenz</a>. Durch Nutzung des <a href="Bidirectional_Forwarding_Detection" title="Bidirectional Forwarding Detection">BFD</a>-Protokolls durch RIP lassen sich Konvergenzzeiten im Millisekundenbereich erzielen.

</p><p>Die nur direkte Bekanntschaft seiner Nachbarn ist auch das größte Problem von RIP. Zum einen ergeben sich hohe Konvergenzzeiten und das <i>Count-to-Infinity</i>-Problem. Infinität bezeichnet die Unerreichbarkeit eines Ziels und wird bei RIP mit dem Hop-Count 16 angegeben.

</p>

<div class="mw-heading mw-heading2"><h2 id="Beispiel">Beispiel</h2></div>

<pre>Netz 1 – Router A ------- Router B ------- Router C

</pre>

<p>Das Netz 1 wird somit erreicht von:

</p>

<ul><li>Router A mit dem Hop 0</li>

<li>Router B mit Hop 1 über Router A</li>

<li>Router C mit Hop 2 über Router B und Router A.</li></ul>

<p>Fällt Router A aus, teilt Router B beim nächsten periodischen Update an Router C den Hopcount 16 mit, was Nichterreichbarkeit oder "unendliche Route" bedeutet.

Trifft nun bei Router B ein Paket eines anderen Routers ein, der Netz 1 noch erreichen kann, ist dessen Hopcount geringer und Router B wird seine Routingtabelle entsprechend aktualisieren.

</p>

<div class="mw-heading mw-heading3"><h3 id="Problemfälle"><span id="Problemf.C3.A4lle"></span>Problemfälle</h3></div>

<p>Ist Netz 1 ausgefallen und sendet Router C seine Routingtabelle an Router B, bevor die Nachricht von der Nicht-Erreichbarkeit des Netzes durch das Netz propagiert wurde, erhält Router B nach dem Update von Router A die Information, das Netz 1 noch über Router C mit Hopcount 3 erreichen zu können. Router C hat seine Routingtabelle ja noch nicht aktualisiert und sendet diese veraltete Information weiterhin an seine Nachbarn, bis er von dort den Hopcount 16 erfährt. Damit übernimmt Router B dann die Route in das Netz 1 mit Hopcount 4.

</p><p>Router B würde beim nächsten Austausch Hop 4 an Router C senden, dieser übernimmt diese Information und trägt Hop 5 in seine Routingtabelle ein, da er bisher bereits Netz 1 über Router B erreicht. Somit schaukeln sich beide Router nur langsam nach und nach bis auf Hop 16 auf, bis von allen Beteiligten Nichterreichbarkeit festgestellt wird.

</p><p>Mechanismen zur Vermeidung spezieller Fälle dieses Problems sind <a href="Split_Horizon" title="Split Horizon">Split Horizon</a>, <a href="Triggered_Updates" class="mw-redirect" title="Triggered Updates">Triggered Updates</a> und (bei RIP mit IP) <a href="Split_Horizon" title="Split Horizon">Split Horizon with Poisoned Reverse</a>. Mit dem Erweiterungsalgorithmus RIP-MTI lassen sich Routing-Loops sogar vollständig erkennen und das Count-to-Infinity-Problem tritt überhaupt nicht mehr auf.

</p><p>RIP erlaubt deshalb nur Netze mit einer maximalen Länge von 15 Routern (d. h. der längste Pfad darf maximal über 15 Router gehen). Daneben hat RIP je nach Version noch weitere Nachteile: Lange Konvergenzzeit, nur kleine bis mittlere Netze, Flutung des Netzes durch Austausch der Routingtabellen bei RIPv1 (alle 30 Sekunden bei IP, alle 60 Sekunden bei IPX) über <a href="Broadcast" title="Broadcast">Broadcast</a>, keine <a href="Subnetz" title="Subnetz">Subnetz</a>-Unterstützung und keine Authentifizierung. RIP wird daher mehr und mehr von <a href="Open_Shortest_Path_First" title="Open Shortest Path First">OSPF</a> abgelöst.

</p>

<div class="mw-heading mw-heading2"><h2 id="Versionen">Versionen</h2></div>

<p>Es existieren drei Versionen von RIP: RIP(v1), RIPv2 und RIPng.

</p><p>Der dem RIP-Protokoll zu Grunde liegende <a href="Bellman-Ford-Algorithmus" title="Bellman-Ford-Algorithmus">Bellman-Ford-Algorithmus</a> wurde im Jahr <a href="1967" title="1967">1967</a> das erste Mal in einem Computernetzwerk als erstes Routingprotokoll für das <a href="ARPANET" title="ARPANET">ARPANET</a> verwendet.

</p>

<p>Die ursprüngliche Spezifikation von RIP in RFC 1058 benutzt noch kein <a href="Classless_Inter-Domain_Routing" title="Classless Inter-Domain Routing">CIDR</a>. Die regelmäßig versendeten Routinginformationen enthalten keine Informationen über die verwendeten Subnetze, so dass alle Netze die Größe der zugehörigen Netzklasse haben müssen. Des Weiteren ist in RIPv1 keine Möglichkeit zur Authentifizierung vorgesehen, so dass verschiedene Angriffe auf das Routing eines Netzes erfolgen können. RIPv1 begrenzt zudem die Anzahl der möglichen HOPs zwischen Routern auf 15.

</p>

<p>Mit der Version <b>RIPv2</b> wurden 1993 einige Einschränkungen beseitigt. RIPv2 stellt den nahtlosen Übergang auf eine neue Version des RIPv1 dar, mit dem Anspruch unter weitgehender Beibehaltung des Paketformates und seines Transportmechanismus die Begrenzung durch die Nichtweitergabe der Subnetzinformation aufzuheben. RIPv2 wandelt sich daher zu einem classless Protokoll <a href="Classless_Inter-Domain_Routing" title="Classless Inter-Domain Routing">CIDR</a> als wichtigstem Unterschied zur Vorgängerversion, besitzt darüber hinaus aber noch weitere kleinere Anpassungen wie die Nutzung von Multicast-Adressen <a href="Multicast" title="Multicast">Multicast</a> für Updates oder Authentifizierungsmöglichkeiten. Viele Merkmale, die RIPv1 prägen, bleiben bei RIPv2 jedoch erhalten. Dazu zählen die Erreichbarkeitsgrenze mit 15 „Hops“, die Verwendung der Mechanismen zur Schleifenunterdrückung und triggered Updates zur schnelleren Konvergenz.

</p>

<div class="mw-heading mw-heading3"><h3 id="RIPng">RIPng</h3></div>

<p><b>RIPng</b> ist in RFC 2080 definiert und enthält Erweiterungen zur Unterstützung von <a href="IPv6" title="IPv6">IPv6</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Paketformate">Paketformate</h2></div>

<td style="background:#F79646; width:25%;">command

</td>

<td style="background:#4BACC6; width:25%;">version

</td>

<td colspan="2" style="background:#EEECE1; width:50%;">must be zero

</td></tr>

<tr>

<td colspan="2" style="background:#F79646;">address family identifier (of net 1)

</td>

<td colspan="2" style="background:#EEECE1;">must be zero

</td></tr>

<td colspan="4">IP address (of net 1)

</td></tr>

<td colspan="4">must be zero

</td></tr>

<td colspan="4">must be zero

</td></tr>

<td colspan="4">metric (distance to net 1)

</td></tr>

<tr>

<td colspan="2" style="background:#F79646;">address family identifier (of net 2)

</td>

<td colspan="2" style="background:#EEECE1;">must be zero

</td></tr>

<td colspan="4">IP address (of net 2)

</td></tr>

<td colspan="4">must be zero

</td></tr>

<td colspan="4">must be zero

</td></tr>

<td colspan="4">metric (distance to net 2)

</td></tr>

<td colspan="4">…

</td></tr>

<td colspan="2">address family identifier (of net 25)

</td>

<td style="background:#EEECE1;" colspan="2">must be zero

</td></tr>

<td colspan="4">IP address (of net 25)

</td></tr>

<td colspan="4">must be zero

</td></tr>

<td colspan="4">must be zero

</td></tr>

<td colspan="4">metric (distance to net 25)

</td></tr></tbody></table>

<p>Die Tabelle ist 4 Bytes breit, Blöcke über net2–net25 sind optional.

</p>

<td style="background:#F79646; width:25%;">command

</td>

<td style="background:#4BACC6; width:25%;">version

</td>

<td colspan="2" style="background:#EEECE1; width:50%;">must be zero

</td></tr>

<tr>

<td colspan="4" style="background:#BBBBBB;">RIP-Eintrag (20 Bytes)

</td></tr></tbody></table>

<p>Die Tabellen sind 4 Bytes breit.

</p><p>Abhängig vom Eintrag im Feld <i>version</i> besteht ein <i>RIP-Eintrag</i> aus einem RIPv1-Eintrag (<i>AFI</i> etc.), einem RIPv2-Eintrag (s. u.) oder einem Authentifizierungs-Eintrag (s. u.). Mehr Details stehen in RFC 2453.

</p>

<div class="mw-heading mw-heading4"><h4 id="Beispiele_eines_RIP-Eintrags">Beispiele eines RIP-Eintrags</h4></div>

<p><b>1. RIP-Eintrag mit Subnet Mask</b> (<i>version</i> muss auf 2 gesetzt sein)

</p>

<td colspan="2" style="background:#F79646; width:50%;">address family identifier

</td>

<td colspan="2" style="background:#EEECE1; width:50%;">route tag

</td></tr>

<tr>

<td colspan="4" style="background:#BBBBBB;">IP Address

</td></tr>

<tr>

<td colspan="4" style="background:#BBBBBB;">Subnet Mask

</td></tr>

<tr>

<td colspan="4" style="background:#BBBBBB;">Next Hop

</td></tr>

<tr>

<td colspan="4" style="background:#BBBBBB;">Metric

</td></tr></tbody></table>

<p><b>2. RIP-Eintrag mit Authentifizierung</b> (<i>version</i> muss auf 2 gesetzt sein)

</p>

<td colspan="2" style="background:#F79646; width:50%;">0xFFFF

</td>

<td colspan="2" style="background:#EEECE1; width:50%;">Authentication Type

</td></tr>

<tr>

<td colspan="4" style="background:#BBBBBB;">Authentication (16 Bytes)

</td></tr></tbody></table>

<div class="mw-heading mw-heading2"><h2 id="Freie_Software-Implementierungen">Freie Software-Implementierungen</h2></div>

<ul><li><a href="Quagga_(Software)" title="Quagga (Software)">Quagga</a> (Weiterentwicklung von Zebra)</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Siehe_auch">Siehe auch</h2></div>

<ul><li><a href="Interior_Gateway_Routing_Protocol" title="Interior Gateway Routing Protocol">Interior Gateway Routing Protocol</a> (IGRP)</li>

<li><a href="Enhanced_Interior_Gateway_Routing_Protocol" title="Enhanced Interior Gateway Routing Protocol">Enhanced Interior Gateway Routing Protocol</a> (EIGRP)</li>

<li><a href="Border_Gateway_Protocol" title="Border Gateway Protocol">Border Gateway Protocol</a> (BGP)</li></ul>

<div class="mw-heading mw-heading2"><h2 id="Weblinks">Weblinks</h2></div>

<ul><li>C. Hedrick: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <style data-mw-deduplicate="TemplateStyles:r250917974">

/* start https://de.wikipedia.org/ */

.mw-parser-output .dewiki-iconexternal>a{background-position:center right!important;background-repeat:no-repeat!important}body.skin-minerva .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/OOjs_UI_icon_external-link-ltr-progressive.svg")!important;background-size:10px!important;padding-right:13px!important}body.skin-timeless .mw-parser-output .dewiki-iconexternal>a,body.skin-monobook .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/MediaWiki_external_link_icon.svg")!important;padding-right:13px!important}body.skin-vector .mw-parser-output .dewiki-iconexternal>a{background-image:url("./_mw_/Link.ernal-small-ltr-progressive.svg")!important;background-size:0.857em!important;padding-right:1em!important}

/* end https://de.wikipedia.org/ */

</style><span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc1058" class="extiw external" title="rfc:1058">1058</a></span></i> – <i><span lang="en">Routing Information Protocol</span></i>. Juni 1988 (englisch).</li>

<li>G. Malkin: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2453" class="extiw external" title="rfc:2453">2453</a></span></i> – <i><span lang="en">RIP Version 2</span></i>. November 1998 (englisch).</li>

<li>G. Malkin, R. Minnear: <i><a href="Request_for_Comments" title="Request for Comments">RFC</a>: <span class="dewiki-iconexternal"><a href="https://datatracker.ietf.org/doc/html/rfc2080" class="extiw external" title="rfc:2080">2080</a></span></i> – <i><span lang="en">RIPng for IPv6</span></i>. Januar 1997 (englisch).</li>

<li><a rel="nofollow" class="external text" href="https://folk.universitetetioslo.no/michawe/research/tools/irvtool/index.html">irvtool</a> – ein RIP-/OSPF-Visualisierungstool (Java/GPL)</li></ul></div><div><div class="zim-footer">

Dieser Artikel wurde von <a class="external text" title="Zuletzt bearbeitet am 2025-08-02" href="https://de.wikipedia.org/wiki/?title=Routing_Information_Protocol&oldid=258515274">Wikipedia</a> herausgegeben. Der Text ist unter <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.de">Creative Commons Attribution-Share Alike 4.0</a> verfügbar, sofern nicht anders angegeben. Für die Mediendateien können zusätzliche Bedingungen gelten.

</div>

</div></div>

</div>

</main>

</div>

</body></html>